1. Field of the Invention
The invention relates generally to the field of backup and recovery of databases and more particularly to the automatic discovery of databases on storage devices so that they can be grouped for backup purposes.
2. Background
Companies and institutions that use databases in their computer systems often have several of them, some of which may be created and managed by software from different vendors. For example, a large multinational manufacturing company may have at one client site a relational database for handling its manufacturing and inventory data. That company's sales department might use a separate relational database for tracking sales and accounts at that same client site. The company's finance department might use still another relational database to track assets and finances at that client site. It is possible that these databases will be stored on the same storage systems at the client site, which can, in turn, be accessed by the same servers or mainframe computers.
In the example given, the inventory data base may be created and managed by software supplied by Oracle.TM. Corporation, while the sales database may be created and managed by software from Informix.TM. Corporation or Sybase.TM. Corporation, or another supplier of relational databases. While such a mixing of software from different vendors is not the most common usage, it does occur with some frequency.
Since most of these databases hold critical information, regular and reliable backups are important. In addition to backups done for each database, most systems administrators consider it prudent to have disaster recovery backups available as well.
Heretofore, systems or database administrators who wished to perform the backups of such databases had to determine what storage units were used by which databases, which type of database used each, and how the different database systems allocated data to the storage units.
Such an effort is complicated by the fact that one of the most common types of database is a relational database and each relational data base has a number of files or tables created for it by the database application program. One Oracle.TM. relational database, for example, may have control files, data files, online redo log files, archive redo log files, initialization parameter files, and a file containing the Oracle.TM. code, among other files. Traditional backup planning requires that the system or database administrator know where each of these files for a given database is located on the storage units available to the system or server. FIG. 5 illustrates how a Sybase.TM.-like database, for example, DB-C, might allocate indexes C66, catalog tables C64, data tables C70, C72, into two logical groupings, system tables C60 and user database tables C68. In turn, these logical groupings may be physically allocated to two different storage units S6 and S7.
A vendor may supply its own backup and restore programs or offer guidelines for using commonly available operating system software utilities to perform backups and restores. Whether unique programs are supplied or only guidelines, these differ from each other and cannot be used interchangeably. That is, the Informix.TM. backup and restore procedures usually will not work with a database from Sybase.TM.. Since each database vendor also allocates data to storage units differently, system-wide backup and restore efforts require a significant a level of expertise on the part of the administrator(s).
Space for each database at a client site may be grouped across several storage devices, as shown in FIG. 2. If two databases from different vendors are allocated to the same storage unit at one client site, and that unit is backed up, all the databases that have any files on that device must be completely restored to preserve database integrity. To illustrate, suppose database DB-C of FIG. 2 is allocated across storage units S6 and S7 and database DB-D is allocated across units S7 and S8. Databases DB-C and DB-D share a storage unit S7. Assume a backup copy is made of storage of units S6, and S7 for database DB-C, using an operating system-level utility. After the backup copy is made, database DB-D is updated by many transactions, but database DB-C remains as it was. If a failure occurs and the backup copy is restored to units S6 and S7, database DB-C is operational again, but database DB-D may be corrupted. This problem can occur even if both databases DB-C and DB-D use the same vendor software.
If a given installation attempts to eliminate the risk of corruption by backing up each database individually, under manual control, using the procedures or programs designated by the vendor, that, too, can be problematic since it is slow and is prone to manual mistakes.
Consequently, if client site complete backups are done using present methods they are usually done either by writing all storage units to backup devices at one time, which restricts scheduling flexibility and requires that all units be restored at the same time, as well, or by requiring that each individual database be backed up by an expert administrator using the tools or system procedures supplied for use with only that database.
It is an object of the present invention to provide a way to discover and backup databases that is more convenient for the user than present methods.
Yet another object of the present invention is providing a method and apparatus to discover and backup databases that requires less user level expertise than present methods.
Still another object of the present invention is providing a method and apparatus to discover and backup databases that is less error prone than a primarily manual process.